The Real-time Transport Protocol (RTP) is a network protocol for delivering audio and video packets over Internet Protocol (IP) networks. RTP is commonly used in communication and entertainment systems that involve streaming media. Further, RTP is one of the technical foundations of Voice over IP (VoIP) and in this context is often commonly used in conjunction with the Session Initiation Protocol (SIP) to establish connections across an IP network. In operation, an RTP session is established for each multimedia stream (e.g., audio, video) and consists of an IP address with a pair of ports. Also, RTP is used in conjunction with the RTP Control Protocol (RTCP) to provide quality of service (QoS) feedback for each media stream and to synchronize between media streams. As such, while RTP carries the media streams, RTCP is used to monitor transmission statistics and QoS, and to support the synchronization of multiple streams.
RTCP can transport statistics for each multimedia stream and information such as transmitted octet and packet counts, packet loss, packet delay variation, and round-trip delay time. An application may use this information to control QoS parameters such as to limit the data flow or to use a different multimedia coder/decoder (codec). For instance, RTCP can provide explicit information on the recommended data rate for streaming video using an RTCP Temporary Maximum Media Stream Bit Rate Request (TMMBR) message, such as described by Internet Engineering Task Force (IETF) Request for Comments (RFC) 5104 (IETF RFC 5104) (February 2008).
Furthermore, in conventional networks that use Transmission Control Protocol (TCP)/Internet Protocol (IP) (TCP/IP), these networks typically control packet congestion by dropping packets. However, Explicit Congestion Notification (ECN) is an extension to TCP/IP that allows end-to-end notification of network congestion without dropping packets, as described by RFC 3168 (September 2001). Further, ECN is an optional feature that may be used between ECN-enabled endpoints when supported by the underlying network infrastructure. When ECN is successfully negotiated, an ECN-aware sending node may set a mark in the IP header instead of dropping a packet in order to signal impending congestion. The ECN-aware receiving node can echo the congestion indication to the sending node, which then reduces its transmission rate as if it detected a dropped packet. As such, ECN-enabled endpoints can send this indication to implicitly indicate a recommended data rate of a multimedia stream.
However, there are currently no mechanisms to explicitly convey information related to the recommended bit rate from a sending node to a receiving node in the communication system, or for a receiving node to request a recommended bit rate from a sending node in a communication system.
Accordingly, there is a need for improved techniques for recommending a data rate and for requesting a recommended data rate in a communications system. In addition, other desirable features and characteristics of the present disclosure will become apparent from the subsequent detailed description and embodiments, taken in conjunction with the accompanying figures and the foregoing technical field and background.
The Background section of this document is provided to place embodiments of the present disclosure in technological and operational context, to assist those of skill in the art in understanding their scope and utility. Unless explicitly identified as such, no statement herein is admitted to be prior art merely by its inclusion in the Background section.